The number of electronic devices in people's homes is continually increasing. Many years ago, homes only had a radio; then, a radio and a television. The number of devices has increased to the point where a typical home has several televisions, stereos, computers, video game consoles, mobile phones/devices, appliances and others. Furthermore, these devices are gaining intelligence so that they are able to communicate with each other.
The expansion of residential networks to include a multiplicity of devices that can share files asynchronously and connect to the Internet through residential gateways was facilitated by the de-facto standard use of wired and wireless ethernet connectivity. Asynchronous sharing then started to give way to buffered streaming of video as bandwidth availability improved. This was closely followed by real time streaming. Networks employ quality of service to manage bandwidth resources and Universal Plug and Play (UPnP) to perform discovery and compatibility of compressed video content. Video UPnP also defines remote user input operation like play, stop and rewind so that video control as well as video display is able to be performed remotely. Also, provisions were made to support graphical transfer of a remote user interface, but no implementations on the market have made use of this. UPnP allowed for many different standards of compressed video but does not, however, certify that a client supported the relevant decoder. Digital Living Network Alliance (DLNA) is a standards body formed to provide certified device compatibility for a specific subset of UPnP implementations. DLNA also defined the role of media servers, renderers, adapters, players and controllers.
A standard, referred to as Remote User Interface (RUI or Remote UI) is being developed to allow devices to operate each other and provide the user with a user interface that is configured appropriately for a device being used to control another device. For example, a user interface for a 46″ wide television is not likely to appear properly on a mobile phone which has a display of 2″. The Remote UI standard is a web-based protocol and framework for remote user interface on UPnP Networks and the Internet. The standard allows a UPnP-capable home network device to provide its interface (display and control options) as a web page to display on any other device coupled to the home network.
There are no well defined and widely accepted UPnP implementations for graphical RUI. One option, which has been backed by the UPnP Forum, is a browser based implementation known as CEA2014. The network client browser is considered to be heavy in flash, memory and/or processor requirements (‘thick’ client), whereas the network server application performs simple encapsulation of XML (‘thin’ server). In some situations this may be acceptable, like the case when rendering is performed by a personal computer and the application is run on a small mobile device, or a low end processing device, like a network router.
However, in the case of the home network where the rendering is done by a high definition TV, a Blu-Ray® player, a picture frame or a gaming machine, the use of a browser for RUI has some disadvantages. Firstly, a browser adds to the already substantial memory requirements of the renderers and so for these cost sensitive consumer electronics devices it may not be viable. Secondly, the processing speed requirements for a responsive experience are not going to be provided by the current range of devices available. And thirdly, the browser interface lends itself well to mouse and keyboard control, but is not necessarily the ideal format for a limited button remote control.
Also, the home network is able to include graphics applications built into game machines, video players, dongles and intelligent remotes on the low end, with cable boxes, cloud servers and multimedia PCs on the high end. To shoehorn all of these into one UPnP standard, it is clear that reach will be limited. In some cases substantial effort of rewriting or translation of the graphics application might be needed in order to fit the browser framework.
Another example of a proposed RUI is being provided through the RVU alliance. The RVU alliance was initiated by DirectTV in order to provide a pixel accurate remotely rendered version of their satellite decoder user interface. Unlike the browser based RUI, RVU uses a low level protocol that manipulates the graphics card framebuffer layers more directly. Instead of the script type messages that CEA2014 uses, RVU breaks up elements of the graphics into images that can be sent compressed or uncompressed over the network to be composited in the renderers screen buffers or off screen buffers as needed. Simple bit commands are sent over the network to allow the images to be stretched, cut and alpha-blended on the renderer side. This type of RUI would be considered a thin network client and thick network server because most of the computation effort would be with the application. Also, because most actions involve sending image data, this type of RUI uses a lot of network resources.
The advantage of RVU is that the low level graphics operations are able to be supported by all graphics cards quite easily and is not directly dependent on the type of application to be able to function. However, sometimes performance is a key parameter in usability, and as such the network load and network server performance could severely limit how useful the protocol is. RVU is especially vulnerable where complete screen refreshes are needed often, like 3D rotations of a view. A browser approach could handle this more simply through scripts of simple rotation commands. Another similar limitation is when the application is providing remote graphics to multiple renderers, and causes the application processor to run short of the necessary MIPS to perform adequately.